home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 14233 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.5 KB  |  69 lines
  1. Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
  2. Path: newsfeed.acns.nwu.edu!ftpbox!mothost!schbbs!news
  3. From: shang@corp.mot.com (David L. Shang)
  4. Subject: Re: What Should An Exception Handling Do? -- Clarification of rules
  5. Reply-To: shang@corp.mot.com
  6. Organization: MOTOROLA 
  7. Date: Fri, 29 Mar 1996 16:25:24 GMT
  8. Message-ID: <1996Mar29.162524.28067@schbbs.mot.com>
  9. References: <4je18p$lnr@dscomsa.desy.de>
  10. Sender: news@schbbs.mot.com (SCHBBS News Account)
  11. Nntp-Posting-Host: 129.188.128.126
  12.  
  13.  
  14. In article <4je18p$lnr@dscomsa.desy.de> mernst@x4u2.desy.de (Matthias Ernst)  
  15. writes:
  16. > I also agree but have some problem about the way the exception handler
  17. > passes back information to the 'thrower'. Or, the other way around, how can
  18. > the 'thrower' ask for dedicated information in an anonymous outer frame
  19. > (a la 'Do you really not want to save your changes ?')
  20. > 
  21. > I fear, for retry-semantics the handler is too near to the thrower, too deep
  22. > in the hierarchy to provide this information.
  23. > 
  24. > try
  25. >   font = getfont(name, size)
  26. > except exc: FontNotAvailable
  27. >   ask_for_new_font(out name, out size)
  28. >   -- Ask the user here ? We're deep in the functional part, 
  29. >      not aware of our user interface
  30. >   retry
  31. > end;
  32. > 
  33. > With resumption-semantics the handler might alter the exception object:
  34. > 
  35. > try
  36. >   init_interface -- which is a deep hierarchy
  37. > except exc: FontNotAvailable
  38. >   ask_for_new_font(out name, out size)
  39. >   exc.new_font_name = name
  40. >   exc.new_font_size = size
  41. >   resume
  42. > end;
  43. > 
  44.  
  45. Good examples. I am not sure whether it is pratically sufficient
  46. if we just provide one-level correspondence between caller and callee
  47. on the retry-semantics base. For example, initialize interface is usually
  48. done in the application develoipers and they should know how to deal
  49. with exceptions like font is not found.
  50.  
  51. If deep levels are involved, resumption-semantics may be helpful to
  52. avoid to re-initialize the whole interface. But we perhaps can
  53. have a retry on the smallest try cloure where the exception is thrown,
  54. rather than a resumption exactly from the point the exception is trown.
  55.  
  56. > But I fear that at the toplevel all the handlers for missing information
  57. > accumulate to a great mess.
  58.  
  59. I agree that to handle deep level resumption/retry is very complicated, and
  60. it seems that there were no neat solution.
  61.  
  62. In my personal experience with a number of user interface designs, I've
  63. been happy with just one-level correspondence between callers and callees.
  64.  
  65. David Shang
  66.  
  67.  
  68.  
  69.